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ABSTRACT 


Recent advances in the design of high performance aircraft, such as fly-by-wire 
controls, complex autopilot systems, and unstable platforms for greater maneuverability, 
are all possible due to the use of digital control systems. With the aid of modern control 
tools and techniques based on state-space methods, the aerospace engineer has the ability 
to design a dynamic aircraft model, verify its accuracy, and design and implement the 
controller within a matter of a few months. This work examines the digital control 
design process utilizing a Rapid Prototyping System developed at the Naval Postgraduate 
School. The entire design process is presented, from design of the controller to 


implementation and flight test on an Unmanned Air Vehicle (UAV). 
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I. INTRODUCTION 


The use of digital computers in the real-time control of aircraft has paved the way 
to new aircraft designs that are faster, more maneuverable and safer than ever before. 
With this growing emphasis on digital control design, new tools and techniques have 
been developed to aid in the design and implementation of complex control systems. 
Traditionally, control systems are developed using classical control design methods that 
are costly and time consuming. Newer technologies, like rapid prototyping based on 
modern control methods, integrate the design process and shorten the time required to 
complete a control design from a few years to a few months. 

The purpose of this thesis is twofold: develop the background material for an 
Advanced Control of Aerospace Vehicles course, and design and flight test an altitude 
hold controller for a UAV. 

At the Naval Postgraduate School, students in the Aeronautical and Avionics 
Engineering curriculum receive a full sequence of controls courses with the final course 
being Advanced Control of Aerospace Vehicles, for which this thesis is written. This 
course will introduce the students to the critical aspects of the design, implementation and 
flight testing of the basic controllers for fixed-wing aircraft. The course examines both 
classical (transform) and modern (state-space) control methods for designing complex 
digital control systems. 

The main focus is on the study of sampled-data systems, systems that have both 
discrete and continuous-time components. Devices used for the interface between the 
continuous and discrete components, the analog-to-digital converter and the digital-to- 
analog converter, are covered in detail. This thesis will derive mathematical models for 
each of these operations, and develop tools for analysis and synthesis. 

The class is largely project oriented. Much of the class is concentrated in the 
Avionics/Controls laboratory and the Unmanned Air Vehicle (UAV) laboratory. The 
projects are centered on a Rapid Prototyping System (RPS) developed by the aeronautical 
engineering department for flight testing control algorithms for unmanned air vehicles. 


The system affords a small team the ability to test new concepts in guidance, navigation, 


and digital control. The RPS consists of commercially available rapid prototyping 
software with an open architecture design to allow for a wide range of applications. The 
application software developed by Integrated Systems Incorporated (ISI), called RealSim, 
allows students to participate in design projects from the initial concept stage to the flight 


testing phase of the design process. This software has two main advantages: 


e The ability to automatically generate higher-language code such as C for the 


designed controller. 


e The system utilizes industry standard I/O devices including digital-to-analog, 
analog-to-digital, pulse width modulation, and serial capability, permitting easy 


connections to hardware. 


The test bed aircraft used is a UAV called FROG , shown in Figure 1.1. This UAV is 
equipped with a complete avionics suite necessary for autonomous flight. 

The accomplishment of this endeavor has led to a number of successful projects, 
including voice controlled flight and an airspeed controller, and is paving the way for 
more complex projects such as autonomous landing. This thesis will describe in detail 
one such design project, the development of an altitude hold controller implemented in 
the FROG using the RPS tools. The automation of the design process is completed in 


three developmental phases: 


e Feedback controller design. In this phase a model of the plant 1s created. The 
controller is then designed through various methods of classical input/output 
control techniques and/or modern state-space control techniques. The process 


typically involves many iterations to satisfy specific design requirements. 


e Hardware-In-the-Loop Testing. The feedback system is tested with some or 
all of the actual hardware which will be used to control the aircraft. This is the 


final validation of the controller prior to an actual flight. 


bo 


e Implementation and Flight Test. The controller is implemented in the Fight 


Management System used to control the FROG and then flight tested. 


The design process described above is completed entirely with the RealSim series rapid 


prototyping software and real-time control hardware integrated with the system. 





Figure 1.1: UAV FROG 








Wl. SAMPLED-DATA SYSTEMS 


The systems and signals studied in the control of aerospace vehicles are referred 
to as sampled-data systems and have both discrete and continuous components, see 
Figure 2.1, where a continuous-time, or analog signal, is to be processed using a 
computer or special-purpose Digital Signal Processing (DSP) chip set. The interface 
between the continuous and discrete systems include the analog-to-digital (A/D) and the 


digital-to-analog (D/A) converters. 


ee Zero-Order-Hold uly) Plant HY Sampler y(K) 
(D/A) (CTS) (A/D) 
Figure 2.1: Sampled-Data System 


The conversion of the a discrete to an analog signal by the D/A converter, which 
usually uses a Zero-Order-Hold (ZOH), involves scaling the digital values and converting 
them to a piecewise-constant continuous output. Where the conversion of the analog 
signal to a discrete sequence by the A/D converter is accomplished by a sample-and-hold 
circuit, called a Sampler. 

This chapter will describe the operations of the digital-to-analog converter and 
analog-to-digital converter and methods for obtaining discrete models of continuous-time 
systems. Material presented in this chapter is in the form of classroom notes, for further 


discussion refer to [Ref. 1,2,3]. 


A. DISCRETE MODELS OF SAMPLED-DATA SYSTEMS 


In this section we establish a general method for obtaining the difference 
equations that represent the behavior of the sampled-data system. The resulting 


equivalent discrete system will then be analyzed using the sample-to-sample discrete 


transfer function of a continuous system between a D/A and an A/D, as shown in Figure 


u(k) Plant y(k) 
ny 


TDs, 


Where 


p- Xx=A-x+B-u 
y=C-x+D-u 


ie = Ag-x, + Ba-t, 
a 
y, =Ca-x, + Da-t, 


Figure 2.2: Equivalent Sampled-Data System 


1. Digital-to-Analog Converters (D/A) 


Digital-to-analog converters usually use zero-order hold or (ZOH): given a 
sequence of samples, u(k7) at t = kT , and holding its output constant at this value until 
the next sample is taken at ¢ = kT + T to produce a continuous signal. The piecewise 
constant output of the D/A is the signal u(t) that is applied to the plant. Thus, the value of 


u(t) consists of steps as seen in Figure 2.3. 


Dd Analog-to Digital Converters (A/D) 


The analog-to-digital converter samples the analog signal y(t) at discrete times and passes 
them to the computer. The time interval between samples y, is called the sampling 
interval 7. The A/D converter has two functions: quantizing the sampled analog signal 
into a discrete set of levels and coding the quantized representation into an acceptable 


format. 





Digital-to-Analog 
Converter 
(DAC) 


Input Output 


Figure 2.3: Digital-to-Analog Conversion 


Ss Discretization of Continuous-Time Systems 


Consider a linear, continuous-time system 
x=A-x+B-u 
y=C-xt+D-u 

then 


x(t) =e") . x(t) 4+ WeAtee -B-u(t)-dt. 


To discretize let: tg = kT ; t = kT + T and assuming uw is held constant over the sampling 
interval T (ZOH with no delay) 

u(t) =u(kT) ; ara + 1 | 
Then 


kT4+T 
x(AT +T) =e x(kT)+ [eT B-u(r)- de 


kT 


Let 
&=(kT+T)-t 
d& =-dt, 
then 
t=ke= €=T 
t— Oa CC —() 


Letx(k7? +7) = x,,,, then 


; 
x, ee le“? -B-u, -dé (Eq. 2.1) 
0 
Define 
7) = pee 
] 
T= |e" -B- dé 


The discrete equivalent of P 


wa = Oo lu 
ine ; (Eq. 2.2) 


Vee © etl) Ue, 
Note the equivalent discrete system 1s shift-invariant, since ® and [I are not functions of 


k. Commands to discretize: Matlab--c2d, Xmath--discretize 


EXAMPLE 2.1: Discretize the following CTS 
X=-a-x+a-u a 
1 


y=x Yee @ 





From equation 2.2 


c~p Z. Dae 


P= fer -(a)-dé =(1-e") 


al ~aT 
“x, +(1—e 


Xypyy =O Neue 


Via 


B. THE Z-TRANSFORM 


1. Definition 


Given a sequence {x;}, k= -0,...0, let 


X(z)= yxy, so ro < 2| < Ro, (Eq: 25) 


where we assume we can find values of r, and for which the series converges. 
As in the case of the Laplace transform, Eq. (2.3) is considered an operator that 
transforms a sequence x, into a function X(z), symbolically represented by 
(2) = Dry 
The x; and_X(z) are said to form a z-transform pair denoted as 


X(z) <> Zixx} 


EXAMPLE 2.2 Consider the sequence given in example problem 2.1 





RG\)=— > xy=e% k=0,1,2.... 
Sd 


By Eq. (2.3) the z-transform of x, 1s 
k 


Lb 50) = SOB) = yew = Ser Zz) 


Note: a infinite geometric sum Is given by 


- l 
S =) a” =— ; a|<| 
p> = la 
Letting a =(e" -z') 
l Sah -| -al 
X(z) = ——————__ ; e oo OR 4) ac 
Oe : | fi 
4p Some Properties of the z-Transform 


Listed below are some properties of the z-transform useful to the material 


presented in this section. For reference, a more complete list is found in |Ref. 1]. 


Linearity: given {x;/, {y:/ 
Z(XK + Vi) = LX) + Li) 
Z(a x t+ vy] = Zlaxy) + Za yy =aX(z)+aY(z)  ; where a=constant 


Time Shifting: 
Z{x(k + n)} = z=" X(z) 
Gives transform pairs 
x(k+1) <> z X(z) 
x(k-l) 2 z! X (Zz) 
Demonstrated by 


Z(Xk+y) = Z (XW) 


co oO 
= +e ie 
Z (Xk+1) = ee a= Ee — 
0 0 


| 
aw 
= 
ae 
pl 
= 
= 
N 


Final Value Theorem: 
Lim x(k) = Lim (2) 


if such limits exists. 


EXAMPLE 2.3: Find the z-transform given in example problem 2.1. 





zX(z) =e" -X(z)+(l-e” )-U(z) eae )aa lao 
Y(z) = X(z) Wie) ze 


C. ANALYSIS OF DISCRETE-TIME SYSTEMS 


iis The Discrete Transfer Function 


Consider the continuous-time and discrete-time systems shown in Figure 2.4. 


u(t) a yi) u(k) TP, | y(k) 
d 


Figure 2.4: System Transfer Functions 


The transfer function for the continuous-time system 1s 
¥(s) = {C(sI - AY! B+ D}-U(s) 


For the discrete-time system compute 
z Mee x, +) a, 
ve —C-x, + Oe 


L(x, ) = Z(@ - x, +a) 
z-X(z)=@- X(z)+ -T-U(z) 


X(z)=(z21 -O)' -T-U(z) 


Z(y,)=Z2(C-x, + D-u, ) 
Z=C-A(Z) + DU) 


¥(z)={C-(zI-®)"' -F + D}-U(z) 
T 


Discrete transfer function 


Y(z) es) 
2) 2GGi-O Tb 
U2) (z/—®) (Eq. 2.4) 


EXAMPLE 2.4: Find the discrete transfer function from example problem 2.1 
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Given: 


a 
SG 


P(s) = 





Continuous- lime 
Y(s) =[C-(sl — A)! - B+ D]-U(s) > Y(s) = ——-U(s) 
S+aQa 


Discrete-Time 


dae" = fe“ (ade = (1-e*”) 


0 


From Eq. (2.4) 


V(z) _ atelier eT) Lee 
Fey 7 Del eT de) = 


Now consider the sampled-data system in Figure 2.5. 


u y 


Figure 2.5: Prototype Sampled-Data System 
Pet 
Ee =0 
u(kT) = 
(ake ea) 


Then u(k) is the unit impulse. The response to a unit impulse determines the impulse 


response of the D/A converter: 


u(t) =1(t)-1l@¢-T) 
Then 


OG) = a aa = -( = e7 | 


S 





and 


y(t) = p (So (I~ -)| 
5 


WAT) = y(t), (kK -DT st skT 


22 


Finally, 
G(z) = Z(W(AT)) 


“ef 224-c1) 
sev fef) 


Sle sale z{ SS) 
5S 


Where the “Z’’” is dropped for convenience. 


EXAMPLE 2.5: Compute the discrete transfer function for 





G(s) = 
Sta 
Then 
Gs) _1 
s S sta 


The corresponding time function 


P oo \(t) -e7“(t) 


y(kT) = \(kT)-—e" -1(kT) 


The z transform 


742! - zor) == = 








-1 z-e” (z-l\(z-e) 


From equation 2.5 


Leni.) 
a aes Fscremeca 





(Bqe2.5) 


The transfer function can also be obtained from the system’s response to a unit 


pulse. Suppose the system input, «, for k > 0, and the initial conditions are known, then 


writing out each term of the difference equation gives: 


Ree Pec eat 1) 


x, =@-x,+T-u, =O-(O-x, +0 -u,)t+T-u, =O -x,+@-T-u,+T-u, 


etme, Dl u eO eel ne en, , 


Therefore, 


k-| 
i Oe, DT a 
i=0 
; k=l _, (Eq. 2.6) 
y, =C-O" -x, +) C-® SD ae 
i h,(k-i) 


ke == () 
Uy, =5 ; 
0;k #0 


f= Sai atin, =h,(k). 


i=0 


Suppose x9 = 0 and 


then 


In general, 


= >A, (k -i)-u, . 


k=-c@ 


De Block Diagrams and State-Space Descriptions 


The discrete transfer function, in the z-domain, represents a linear algebraic 


relationship, accordingly multiple linear systems may be described by a system of linear 


equations. 


Parallel Connections: The system response of a parallel combination of two LTI 


systems is the sum of the single-path transfer function, Figure 2.6. 





Figure 2.6: Parallel blocks 


Y(z)=[A,(z)+ H,(z)|-U(z)= A(z)-U(z) 
H(z) 


Cascade Connections: The system response of two LT] systems in series is related by 


the product, Figure 2.7. 


fe } fe > 


Figure 2.7: Cascade blocks 


¥,(z) = H,(z)-U(z) 


¥(z)= H,(z)- hort (2)= H(z): H,(2)-U(z) 


Feedback Connections: The transfer function of a single loop, Figure 2.8, is given by: 





Figure 2. 8: Feedback transfer function 
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y=H,-e gO ay, 


1+ H,(z)- rr 


fsy=m ‘(u-H,-y)=> Y(z)= 
e=u-H,-y ‘ 


These transfer function relationships can be used in combination to describe 


complex multi-path systems. 


In general 


ay +a, Waa Sao hal a(z) 
1+5,-z' +b, “z +...0amz” (z) 





H(z)= 


Example of 3" order system 


-] -2 -3 
Oops Si Oic, A aS PRC A 
Bie = ] 2 3 


1+5,-2'+b,-2°+b,-27 


State-space realization (control canonical form), Figure 2.9. 





X 34 X > X yf 
“S60 é 


Figure 2.9: State-Space Realization 


By inspection 
x(k +1) = x,(k) 
x(k +1) =x,(x) 
x,(k +1) =—b, -x, (eb, -xp(k)— 0, - x, (4) + 


y=a,-x,(k)+a,-x,(k) +a, -x,(k) 


16 


In vector-matrix form 


x(k +1) = @0-x(k)4+T -u(k) 


ae v I v 
= ae Ded 0 | |e 18 
ae =), aa, =O) ] 
y(k) =C-x(k) 
C=la, a, a] 


3: Input/Output Stability 


Suppose ee, <M <~, forall k > 0, then Py is BIBO stable if in response to any 


bounded input uw; , the output y;, is also bounded: | y ‘| <oo, fork > 0. 


In general, for zero initial conditions, [ x(0)=0 | 


y= Liha (k-i)-u, 





k=-00 
For BIBO stability 
il =|Sace—-9M < > |h,(k - i) M| 
k=-00 k=-0 
<M. Slh(k -1) <0 
k=-00 
if 


lh (k-i<0 or 0) <0 


Therefore, if the unit pulse response is absolutely summable, then the system is BIBO 


stable. 


EXAMPLE 2.6: Determine the stability requirements for example problem 2.1. 


Consider the unit pulse response 


y, =h, (kh) =a" ieee 1) 20 


and 





= ] 
Keres 
2° “Ta 


is BIBO stable if ja] <1, and unstable otherwise. 


D. SIGNAL ANALYSIS AND DYNAMIC RESPONSE 


I. Signal Transforms 


The unit pulse: 








= Lk =0 
C= > thoe Sz sll. i 
a uli : a 
The unit step: 
= ] Z 1Lk=0 
U(z)= TRS gee 4 = : u,=s- 
@) pa) ; 2 Log z—| : ics 


General sinusoid: 


u,=r 


Jie 


e- 


" .cos(k@) -1(k) = a 


] 





cos(k6)-10)1= 3] 7 +5 | 
rh 


we) Ae Se) . 
z —2r(cos@)z+r 


a Frequency Response of DTS 


Consider a sinusoid at frequency 9 applied to a continuous-time system 


u(t) = A-Ccos(a@, : 6) 


The continuous-time response 1s 


y(t) = A-cos(@, -f+¢) 
Where the amplitude and phase are defined as 
=|G(ja,) 
? = ZG(ja) 
For discrete-time systems 
u, = COS(@, kT) -1(t) 
The discrete transform 


U(z)= 


Z (Ziel COSC => Z 
2 |z-e 


% 
= 5 ee a ae where; — lO =a 
Z —2eCOsD aa) " z-e 
The discrete response 


Y(z)=G(z)-U(z) 
> Gi@)z mn G(z)z 


z- eit mem e 1008 


Expanding Y(z) and letting z > e’”” 


y(y=t je i) Ge® >| 


in z— e. 101 


Let Ge } = A(@,T’) ‘ el¥(!) 


l elYs els 
lea a rT 
2 |z-e"™ Z—er ” 


The inverse transform 


Y (kT) = A-cs(@,Tk +y) 


3. The Discrete Fourier Transform (DFT) 


Let the time function be periodic, i.e. {(AT)=f(kT+NT7T), then DFT of f(k7) can be 
defined as: 





Pes oJ 2a(nkT (NT) 
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Where F(n) is a z-transform of the f(kT) over one period evaluated at the discrete 
frequencies of a Fourier series z =e’® , where @ = ey . Define F, = F(2an/NT), 


Then the DFT can be rewritten as 


N-1 ‘ 
—j2a(nk)/N 
De > Ha! 
z : 
and the inverse transform 1s 
1S j2nx(nk)/N 
=—>) Fe 
ip e n 


Now evaluating the frequency response using the DFT can be done as follows: 
et 
u(kT) = Asin( 27 =a 


Then 


U =) A:sin eas e J2mmkIN 
hl N 


ae + f j2ak(l—n)/N _ o- aaa 





2] 
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ni} 
and the DFT of the output is 
y(kT) = B- inl zai + v) 
N 
N-l , 
Y= py B. sin( 2 + y je mk 
k=0 N 
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ae 
Therefore the transfer function for @, = = is defined by 


Gf ea/N 4 
U, 


where ¥; = FFT(y,) and U; = FFT (u;), evaluated at n=. 
of. inate Nees 
C, A 
E. SAMPLED-DATA SYSTEMS ANALYSIS 


For the purpose of studying the sampled-data systems, each operation involved 
will be analyzed separately. First consider the ideal sampler shown in Figure 2.11. The 
technique presented here is to use impulse modulation to form the mathematical 
representation for the process of taking periodic samples from r(t) to produce a sequence 
r(kT) and to analyze the sampled signal as a continuous signal using the Lapace 


transform. 


ry a ri 


Figure 2.10: Ideal Sampler 


The output of the sampler is a train of impulses 


r (p= S(t) 6(t- kT) 


k=-0 


Recall the following properties of the unit impulse 


[ (t)-d(t-—a)dt = f(a) sifting property and 


[s(c)ar = |(r) 


Therefore 
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Ip ir ())}= fro -e dt 


= [Sor(n)d(t- kT) -e "dr 
wok = 


co 


= > [roe - kT). SG 


k=-D _& 


=e. — i (s) 


where we used the sifting property of 6. 
Now consider the hold operation, which takes the impulses produced by the 


sampler and extrapolates the data into a piecewise constant output r;, as shown in Figure 
ale 


r(t) ry) lh 
+" +] 20H | 


Je 


Figure 2.11: Sample and Hold 


Using zero-order polynomials, thus, the name zero-order hold (ZOH), which hold 
each sample constant over the sampling period, the piecewise signal r, is defined as 
rh=r kT) ; kT << (k+)T 
The response of the ZOH to a impulse at time /=0 is 1 for 0 <¢ < 7. The impulse 
response of the ZOH is ZOH(t)=1(t)-1(t-T). Therefore, 


aD 


-s7T 
ZOH(s) = [l()-10-T)]-e™ «dr = 2 
0 KY 
l. Spectrum of a Sampled Signal and Aliasing 


e * . ° . e e . e . 
Since r (t) is a periodic function it has a Fourier series representation: 


s 5(t-kT) = S Cage = iG. an 
k=-a 


t=—O p=—-0 


tO 
Ko 


where 
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Therefore, 
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ia ie N=—00 
Let w, =— , be the sampling frequency and take the Laplace transform of the sampler 
output: 
L(r (t)) = Sr -80-4T) "a 
) | = not =< 
~ fron} me le “dt 
—o 8 i=—0O 
_ l a t mot “4 
=F 2 Jri-e Foe eli 
P ae I 
Lets =j/o@ 


— le . 
Ro Jaa > Rja- jno,) 


Notice, that sampling produces an infinite train of sidebands at n@ 


n= —-0O...0. 


EXAMPLE 2.7: Let a, = 1, @); = 1/8 


R(j1/8) =...+ R(j@,) + RL j(@, — @, )] + RLF(@y, — @,)] + 


..+ R(j1/8) + RI 7 (—7/8)| + RE j(-14/8)] 


If RG@) has components above the Nyquist frequency @,/2 or 7/7, then after sampling 


overlap or aliasing will occur and the original signal can not be reconstructed. This leads 
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to the sampling theorem: the original signal can be recovered from its samples if the 
sampling frequency (@, = 27/T) is at least twice the highest frequency in the signal. To 


avoid aliasing a low-pass anti-alias filter is usually inserted preceding the sampling 


operation. 


2 Data Extrapolation 


To recover R(jq@) pass R’ through a low-pass filter Z(j@) as shown in Figure 








Zale 
R(ja) = Lia) R (jo) 
Figure 2.12: Ideal Lowpass Filter 
Then 
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Note, the ideal extrapolator 1s noncausal, since /(t) is nonzero for t< 0. Suppose L(y) is 
replaced by ZOH. 
Recall, 


— jor 





ZOH (ja) = — 
Jo 


Expressing the transfer function in magnitude and phase form 
ZOH(jo)=T-e 1"! sine{ 
Therefore, 


IZOH (ja)| =T 





. oLr 
sinc —— 
D, 


ZZOH (jo) = =e +180-5(@—n2z) 


The resulting signal contains unwanted harmonics or impostors. By frequency analysis 


of r(t) the principal harmonic can be identified. 


Consider the sinusoid signal v(t) = e’°"*’” 


V (jo) = [&IOet OP) IM ey 


—cO 


This integral is not defined, however notice Z(d(f)) = fe oS JOlieaie= 


aa 
6(f) =— Ie'" da. 
(1) sg 
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Now replace ¢ with @ to get 


l oO 
LO ele at 
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Therefore, 


co 


V(ja) = |e 


—c 


= 27 ho — 0, ) 


(Ja t+je) o Jat Fp 


Since 6 is a even function, the spectrum of r(t) can be written in terms of impulse 


functions 
RUo)= Ale! *S(@-@) +e “S(@+a, ) 


To recover the signal R, , multiply the spectrum of R’ by the transfer function of the 
ZOH. 


F. DISCRETE EQUIVALENTS BY NUMERICAL INTEGRATION 


Concept: Represent a given continuous transfer function H(s) as a differential 
equation and derive a difference equation whose solution 1s an approximation to that of 


the differential equation. 


I. Numerical Integration 


When considering discrete approximation to integration, as shown in Figure 2.13, 


three alternatives exist. 


Forward Backward Trapeziod 
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Figure 2.13: Area Approximation Rules 


Approximation methods: 


Forward: 
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Therefore, given a continuous transfer function H(s) a discrete equivalent can be 


found by the substitution: 
2) — H(s)| s=Q/T){(z-1)/(z41)) 


Wj) 


Des Zero-Pole Mapping Equivalents 


This technique consists of a set of rules for locating the zeros and poles and 
setting the gain of a z-transform that will describe a discrete, equivalent transfer function 
that approximates the given H(s). 

Rule #1: All poles of H(s) are mapped by z = Pa Replace s with e” for the poles of 
H(s). \f H(s) has a pole at s = a, then H(z) has a pole at z = e’ If H(s) has a complex 


pole at s = -a + jb, then H(z) has a pole at z = re*’’. 


Rule #2: All finite zeros are mapped by z = e%”. 
Rule #3: All infinite zeros of H(s) are mapped by z = -1. 


a) Only one zero of A(s) at s = «© 1s mapped into z = oo. 


Rule #4: The gain of the digital filter 1s selected to match the gain of H(s) at the band 


Center. 


H(s =0) > H,(z =1) 


3. Zero-Order Hold Equivalent 


If the approximating hold is the ZOH, then the equivalent to H/(s) is 


H(z)=(1- e742) 


S 


This is the same relationship that was derived earlier in section C of this chapter. 
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Il. INTRODUCTION TO RAPID PROTOTYPING 


The primary tool for the research conducted in the Avionics lab is the 
hardware/software interface provided by the MATRIX, product family developed by 
Integrated Systems Inc. (ISI). The MATRIX, product family is shown in Figure 3.1. 
This software provides a complete workbench for control systems design and 
implementation. The RealSim controller automates the development of the real-time 
systems by combining graphical modeling software with real-time control hardware. The 
key feature of this product is the AutoCode tool which will automatically program 
higher-language code such as C or ADA for the ‘designed controller. The software 
consists of an easy to use graphical user interface (GUI) that can be run on either SUN 
workstations or a PC. The interface interacts with a high-speed digital signal processing 


(DSP) board developed by Texas Instruments. The system is called AC-100 Model C30. 


MATRIX, Product Family Functionality 





Figure 3.1: MATRIX, Product Family 
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A. RAPID PROTOTYPING SYSTEM ARCHITECTURE 


The rapid prototyping system architecture consists of a UNIX workstation and a 
windows based PC host computer which is equipped with two ISA bus adapter boards 
(Figure 3.2). The workstation and PC are connected through Ethernet, using the standard 
TCP/IP protocol suite. The two hardware boards in the PC consist of a board which acts 
as the motherboard for the C30 DSP, and a “DSPFLEX” carrier board which holds four 
input/output, or “IP”, modules. The I/O boards connect the model to the real hardware 
via the Hardware Connection Editor (HCE), which will be discussed in later sections. The 
complete system is referred to as the AC-100 Model C30 real-time controller. 

The avionics lab currently has two PC’s configured as described above: a Pentium 


tower PC called America and a luggable PC called AC/00. The luggable PC is normally 











Workstation 
RealSim User Interface and Data Collection 









Host Computer 
DSP C30 Processor 


Generate AutoCode C 
I/O Management 






Hardware 


Figure 3. 2: RealSim Architecture 


30 


connected to a stand alone Sparc If workstation, used for field fight testing with the 
school’s Unmanned Air Vehicle (UAV) called FROG. 

There are a number of different types of I/O cards available depending on the 
application. Currently both PC’s have 4 IP modules consisting of a serial communication 
(IP_Serial) module, digital-to-analog (IP_DAC) module, analog-to-digital (IP_HiADC) 
module, and a pulse width modulation (IP_68332) module. A description of each IP 
module and procedures for connecting hardware to the model is covered in detail in the 


Hardware-In-The-Loop Testing section of this thesis. 


B. XMATH/SYSTEMBUILD 


Xmath/SystemBuild is a software program similar to the Matlab/Simulink 
software programs. Xmath is the parent process and will launch the SystemBuild editor 
when the build command is given or when a file is loaded that contains SystemBuild 
data. It was designed to include an extensive set of design and analysis functions for both 
the classical input/output control techniques and the modern state-space control 
techniques. The SystemBuild program uses a hierarchical method of organization, based 
on the SuperBlock concept. SuperBlocks provide a way of organizing a group of blocks 
that define a function into a compact form for display. Through the use of this hierarchy, 
variable names can be passed up and down the hierarchical structure allowing the 
engineer to easily track and understand what variables are and where they interact with 
the model. This section will cover the basic functions of Xmath/SystemBuild, for 


detailed information refer to [Ref. 4]. 


1. Xmath Basics 


Xmath can be run from either the SUN or SGI workstations located in the 
avionics and aeronautics labs. Prior to using the MATRIX, software, the user must 
configure his UNIX account to source the ‘acl0Qsetup’ file which defines the editor used 


by the system. This command should be set up as a marcro in the user’s .cshrc file so it 


By 


will automatically run each time the user logs on to the workstation. Adding the 
following command line to the .cshre file: ‘source$ISI/AC100/bin/ac100setup.sh’, will 
accomplish this. 

Before invoking Xmath, a separate directory for each project should be created to 
avoid using project files from one project with the standard files of another project. 
Therefore, start by first creating a project directory and then move to that new directory 
using the following UNIX commands: mkdir project_name, cd project_name. To start 
Xmath type << xmath >> in the console window. This will bring up the Xmath 


command window as shown in Figure 3.3. 


This is the 
X Windows 


default menu. —»[(yp————vrrath onmnanst an 
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Results appear 


i inaivece con Menu Bar Scroll Bars 


Errors, warnings, 
and messages 
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Figure 3.3: Xmath Command Window 


Di SystemBuild Modeling 


This section 1s a tutorial that covers the basics of the SystemBuild editor and 
simulator. In the following example, the user will build a block diagram and simulate its 
operation. The model for this illustration is a simple Speed Controller shown below in 


Figure 3.4. 





Figure 3.4: Speed Controller 


Step 1: Defining the SuperBlock 

To invoke SystemBuild, at the Xmath command line type << build >> and press 
retumn. The SystemBuild menu bar will appear across the top of the display. Select 
Build from the menu bar with the left mouse button. Then select Edit SuperBlock from 
the Build menu. The Edit SuperBlock dialog box will appear and initially the menu in 
the box is empty. Click the left mouse button on Edit New SuperBlock, and the 
SuperBlock Attributes dialog box appears. Using the SuperBlock Name field, name the 
SuperBlock. Under Type, select Continuous and click DONE. 


Step 2: Placing the Blocks 

A new SystemBuild editor window should be displayed, ready for building the 
block diagram. To select from the SystemBuild block library, click on Define Block 
from the Edit menu or, using a shortcut, double-click in the empty window to bring up 


the SystemBuild block menu. The SystemBuild blocks are grouped together in thirteen 
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palettes. To select a palette, click on one of the three-letter combinations at the top of the 
menu. 

To begin building the Speed Controller, first select the Gain Block from the 
algebraic block palette (ALG). Click and hold the left mouse button on this block, drag it 
into the screen, and release the mouse button when the Gain block dialog box appears, 
name the block, if desired, and click DONE. Next, select the Summer block from the 


AGL palette and the Inegrator block from the DYN palette using the same procedures. 


Step 3: Connecting the Blocks 

The next step is to connect the blocks. Note the middle mouse button will be used 
to make connections. Start by connecting the Summer block with the Integrator block. 
Click in the Summer block, with the middle mouse button, then click on the Integrator 
block. A line should connect the two blocks. Using the same procedure, connect the 
Integrator to the Gain block. Now, connect the Gain block to the Summer block. Since 
there is more than one input to the Summer, the Connection Editor will appear as shown 


in Figure 3.5. Use the connection editor to specify the connections; the inputs to a block 





Figure 3.5: Connection Editor 
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are in numerical order from top to bottom. The output from the Gain block should go to 
the second input of the Summer. Then with the left mouse button’ connect to Gain block 
with the number 2 Summer input, highlight Add and click Done. 

Note that the blocks can be resized by clicking on the block id number and 


moving the mouse, or flipped by double-clicking on the block’s body. 


Step 4: Connecting External Inputs and Outputs 

Input connections: click the middle mouse button in the open space, then in the 
Summer block. The connection editor dialog box appears. With the left mouse button, 
click the number 1 port of the Summer block then click Done. To label the external 
input, click and hold the left mouse button in the SuperBlock ID bar, just above the 
SystemBuild window. Select SuperBlock Attributes. In the dialog box, select the Labels 
tab and under Input Naming select Enter Local Label Names. Now select the Input 
tab and beside Input Label type the desired name. Click Done. 

Output connections: With the middle mouse button click in the integrator block, 


then click in an open space. Connect the two boxes, then click Done. 


Simulating the Model 
The Speed Control model can now be simulated. There are a number of different 


methods to simulate model, two of which are described here; 


Method 1: First define a time-vector in Xmath by specifing a name, range, and 
an increment. In the Xmath command window type: << f=/0: .J : 20]' >>;. Next, 
specify an input vector of magnitude one: << u=ones(t) >>;. Enter the simulation 
command. Type: << y=sim(“Name of Super Block”, t , u) >>;. Note in this example the 
name of the SuperBlock is Speed Controller. This command invokes the simulator, 
specifies that the Speed Controller model SuperBlock is to be processed, and sets the 
output equal to y. After the simulation is complete, plot the output by typing: << plot(y) 
>>. Note, more details on using the sim command are available by typing << help sim >> 


in the Xmath command window. 
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Method 2: From the menu bar under analysis select Simulation. This will bring 
up the simulation parameter dialog box. Define a time vector and input vector as above 


and run. 


Analyzing the Model 

The Xmath/SystemBuild software contains an extensive set of functions for 
system analysis. Specifics for analyzing the model can be found in the Xmath and 
SystemBuild Core Manuals located in the avionics lab or by using the help command. 

To linearize the model, the Xmath command is << _ sys=lin(“SuperBlock 
name ’, {keywords}) >>, where sys is the name of the Xmath system object in state-space 


form. Other useful commands include: poles(sys), eig(a), bode(sys). 


Saving the Model 
To save the model select File from the menu bar, highlight the SuperBlock name 


and click on Save. 


C. REALSIM SERIES RAPID PROTOTYPING 


This section will continue with the design of the speed controller presented in the 
last section. The tutorial will demonstrate the basic procedures for using the GUI and 
testing on a real-time controller. Later sections will describe how the hardware is 


connected to the model and the procedures for hardware-in-the-loop testing. 


1. RealSim Graphical User Interface (GUI) 


Each RealSim project is placed in a unique RealSim project directory. A number 
of standard files are associated with each RealSim project. Therefore it is recommended 
to create a separate project directory for each project. The project name and the directory 


name should be the same. 
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To invoke the RealSim GUI type << rea/sim >> in the UNIX command window. 
When the RealSim GUI is invoked in a new directory a dialog box will appear along with 
the GUI. Pressing return or clicking yes in the dialog box will enable the makeproject 
command which creates the first of the required standard files called animation 
configuration file (animation.cfg). Once all the default settings have been accepted, the 
project name in the bottom left-hand corner of the GUI should be listed. 

Next the user must create a target configuration file (target_config.cfg) file. This 
file contains information such as the settings that the AutoCode needs to generate the 
appropriate C code, which controller the model is to run, how many processors are in the 
controller. This file will be used later to compile, link, download and run the design. To 
create this file, click on show utilities in the GUI and select Retarget. The target is the 
node name of the controller. In the UNIX command window the user will be asked for 
the ‘controller host name[ |:’ which in the avionics lab is ‘america.’ All of the remaining 
default settings should be accepted. After retargeting the system to ‘america’ the GUI 
should indicate this in the middle of the bottom line in the GUI, see Figure 3.6. 

These files are only created once for each project, as long as there are no changes 
to the system configuration. Once these standard files have been set up for a specific 
project, and the user is in the project directory for that project, typing << realsim >> in 
the UNIX command window will start the GUI targeted accordingly. 

Through the use of the GUI the designer can now follow the flow diagram that 
steps the user through the design process. As the user performs each step of the process, 
the GUI paths are filled in, indicating the current stage in the design process. If certain 
RealSim files are older than their logical predecessors, the Needs Up dating indicator will 


be displayed. 


Ze Building the Model 


The first step in the process is building the model using Xmath/SystemBuild, as 
described in the previous section. To continue with the speed controller model, click on 


the Xmath/SystemBuild block in the GUI. This will bring up the Xmath command 


SH. 


window. From this window, select file and load from the menu bar. Highlight the file 
name and click OK. Select the SuperBlock from the build menu to display the model of 


the Speed_ Controller. 
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Figure 3.6: RealSim Graphical User Interface 


The SuperBlock design, for this example, is presently a continuous type and needs 
to be transformed to a discrete controller (z-domain). Selecting Transform SuperBlock 
under Build from the menu bar will display the transform dialog box. Highlight the 
SuperBlock name and under type select Discrete, then click Transform. When 
transforming from continuous-time to discrete-time a time delay block must be added to 


the block diagram, as shown in Figure 3.7. From the DYN palette select the time delay 
block. 
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Contraller 





Figure 3.7: Discrete SuperBlock for Speed Controller 


3: AutoCode 


Once the SuperBlock is complete, the user must generate real-time code. In 
SystemBuild, select Generate Real-Time Code from the Build pull-down menu. When 
the dialog box appears, highlight the SuperBlock for which you want to generate code. 
Beside the generated code language, select RTF_only, and check that the filename is the 
same as the project name, then click DONE. This produces a file with the model name 
followed by a .rtf extension. This file containing the real-time code is a top level 
input/output code that is used by the AutoCode program to produce a higher-level 
language used to conduct hardware-in-the-loop testing. 

After the user has generated a real-time file from the SystemBuild model, 
invoke the AutoCode by clicking the AutoCode button in the RealSim GUI. The 
AutoCode high-level language code generator reads the real-time (or .rtf) file and 
produces a high-level source code file with the extension of .c. This file will be used to 
compile, link, and run the design. The GUI should now indicate the completion of the 


AutoCode process. 
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4. Interactive Animation 


The next step is to build the [nteractive Animation (IA) picture display for 
monitoring and controlling the model while it is being executed in the workstation 
simulation environment or during hardware-in-the-loop testing. Invoke the editor by 
clicking on the Interactive Animation Builder button in the GUI. The animation diagram 
is made by selecting icons from a given library of gauges, dials, switches, and other 
various input and output devices. The Interactive Animation section of the AC100 User’s 
Guide [Ref. 4] has details on all of the available icons. Selecting DEFINE from the IA 
control panel will display the library of icons. For the Speed Controller example select 
the dial for the input and a digital readout for the output as shown in Figure 3.8. The 
RTF NAMES button in the control panel loads the I/O names from the model .rtf file and 
must be loaded prior to making any connections. Using the IA Connection editor, 
similar to the SystemBuild editor, the appropriate inputs and outputs are connected to the 
appropriate devices. Once the picture is complete select SAVE PICT from the control 


panel and a file with a .pic extension is created in the working directory. 


Speed_Controller 


Velocity_Ouput 
Velocity Input ¥_—VUP 





Figure 3.8: [A Speed_Controller 
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> Hardware Connection Editor (HCE) 


The Hardware Connection Editor is used to make connections from the external 
I/O in the SystemBuild model to either external hardware I/O devices for hardware-in- 
the-loop testing or to the IA module for simulation. Before invoking the HCE, the user 
should have a copy of the file “c_c30.hce’ in the project directory. This file informs the 
HCE what type of external I/O devices the target computer, America, is equipped with. 
This process will be covered in greater detail, along with the current set-up in the avionics 
lab, in the Hardware-In-The-Loop Testing section of this thesis. 

Two connection editors will appear when starting the HCE. The first screen is for 
the SuperBlock external inputs and the second for external outputs (see Figure 3.9). For 
this example, the input device will be ‘MONITOR_INPUT? type. No changes should be 
required to the editors and the only action by the user should be to click DONE to both 
pages. 
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Figure 3.9: HCE 
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6. Compile and Link 


Once the AutoCode is complete the C source files need to be compiled and linked 
to the C30. Selecting the Compile and Link button in the RealSim GUI will cause the 
UNIX systems to connect via ftp with the AC100 target computer (America). For this to 
happen the host computer, America, must be in the ftp mode. Typing ‘acl0Qsvr’ at the 
DOS prompt on America will enable the computer for ftp transfer. The compiler 
generates object code from the .c file and the link creates a C30 DSP executable from the 


object code. 


7. Download and Run 


When all the above steps are completed, the model is ready to be tested. The 
testing for this illustration will be a simulation only, since no hardware is connected. 
Selecting Download and Run on the GUI will connect the RealSim software to the target 
AC100 computer through ftp. Once the connection is made, it will automatically load the 
C30 executable into the C30 memory and prepare it to run. The IA module will appear 
on the workstation window along with a control panel called [A Client, see Figure 3.10. 

The START CONTROLLER button starts the execution of the model using the 
initial values loaded from the project _name.ioc file for the external inputs, and outputs 
defined by the SystemBuild model. The STOP CONTROLLER button stops the 
executing application and holds the external inputs and outputs at their final values. The 
RESTART CONTOLLER button restarts the model, again using the initial values that 
were loaded from the project_name.ioc file. 

The HARDWARE RESET button causes the RealSim controller to perform a 
hardware reset and causes the IA Client to exit. This is the best way to exit after a run, as 
it will clear the C30 memory and return the AC100 computer to a ready status. The third 
button, EXIT GRAPHICS, exits the IA Client without rebooting the controller. This is a 
software reboot only, which stops the model and terminates the ftp connection. This 


button is not recommended for use, as it will not stop the model from running on C30. 


Sidac6 lactient Control Window 


HARDVARE START 
RESET EXIT ATA 
<CaUTION> GRAPHICS ACQUISITION 


Figure 3.10: IA Client 
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8. Data Acquisition Editor 


The RealSim data acquisition editor defines one or more data acquisition sets for 
each project and provides real-time data acquisition. This allows the user to record and 
analyze any of the inputs or outputs associated with the project. To invoke the data 
acquisition editor select ‘Data Acq. Editor’ from the show utilities button in the GUI. 
The first data acquisition screen to appear contains all the inputs to the system. The user 
selects the desire inputs for recording by highlighting the variable and selecting “ON” 
next to the DA Setting modifier field at the bottom left of the screen. The 
‘DA_ Decimation Factor’ should read ‘1’, this ensures the value will be recorded every 
time step. To select the outputs for recording, toggle the ‘Display’ selector at the bottom 
of the screen from the ‘SB_INPUTS’ to ‘SB OUTPUTS’. 

The START DATA ACQUISITION button starts/stops the data acquisition 
program which will record any or all of the inputs and outputs to the C30. Starting the 
data acquisition creates a file in the project directory with the project name and *_1.raw’ 
extension. Each time the acquisition process 1s started a new file is created and the 
number will increment up corresponding to the number of data files created. Therefore it 
is good practice to note which data files correspond to which runs when testing. 

To retrieve the data after the exiting the controller, the user selects ‘Convert DA 
Data’ from the show utilities button in the GUI. The workstation command window will 
show the last data file recorded with a ‘.dat’ file extension. The user can accept the file 


listed in the window by pressing return or select a previous file by changing the number 
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of the file. This process creates a file with the same name’as the corresponding raw file 
that can now be loaded directly into Xmath for analysis. The variable names will be the 
same as those used as the input or output names in the SystemBuild model. These 
variables will be vectors with lengths depending on the amount of time that data was 
recorded. A reference file is also created when converting the data that contains specific 
information on that data file, such as the amount of time recorded or the number of 
elements in the file. This will help identify data files if numerous runs are made during 


testing. 
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IV. HARDWARE-IN-THE-LOOP (HITL) 


This section outlines the process of connecting hardware to a digital controller. 
By using the standard input/output devices integrated with the RealSim software, the 
SystemBuild diagram is connected to the desired hardware. A critical part of connecting 
hardware to the controller is the calibration of the sensors. The controller uses an 
algebraic conversion of the measured sensor output signal from the hardware. This 
algebraic conversion requires calibration by determining the correct conversion constants. 

To demonstrate this step of the design process in the avionics lab, a device called 
the Airborne Remotely Operated Device, AROD, will be used. The lab currently has two 
AROD devices which the students will use for calibration and HITL testing. A complete 
description of the AROD 1s given in [Ref. 5]. 


A. HARDWARE DESCRIPTION FOR AROD 


The control surfaces of the AROD are actuated by Futaba FP S34 servo motors. 
To control these actuators, a Pulse Width Modulation (PWM) input signal is used. The 
width of the pulse determines how far the servo will turn. The internal control circuit of 
the Futaba motor includes a small potentiometer in a feedback loop to sense the servo 
position. The output signal from this sensor is noisy due to the varying current draw 
during motor operation. Therefore, the actuators installed on the AROD in the lab have 
been modified to reduce sensor noise. An additional wire has been added so that the 
positive voltage on the potentiometer could be measured at the same time as the center 
voltage [Ref. 5]. Taking the difference between the measured high voltage Vy and the 
centered voltage V- , give a delta voltage Vp and results in a significant reduction in 


sensor noise. This set up is shown in Figure 4.1. 
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PWM Analog Signal 


Figure 4.1: Futaba Actuator 


B. CONVERSION SUPERBLOCKS 


For this design, the controller input commands are given in degrees. Since the 
input signal to the actuators operates on PWM, a conversion from degrees to PWM must 
first be implemented. Similarly, the output signal from the sensors must be converted 
from volts to degrees. Figure 4.2 shows the SuperBlocks that will be developed to 


implement this design. 


Deg_cmd Deg_ sensed 
Deg 2 PWM Actuator Volts 2 Deg 


Figure 4.2: Conversion SuperBlocks 


1. Converting Degrees to PWM 


Previous testing of the actuators has determined the total throw to be 0 to 200 
degrees, with a pulse width of 0.6 milli-seconds corresponding to the minimum 
deflection, 2.4 milli-seconds corresponding to the maximum deflection, and a pulse- 


width of 1.5 milli-seconds corresponds to the centered position, [Ref. 5]. 
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The refresh frequency for the AROD HITL test was chosen to equal the controller 
frequency of 25 Hertz, giving a period 7 of 40 milli-seconds. Figure 4.3 depicts the 


relevant quantities for a PWM signal. 


Ht 


0 _ = pecs ae | —_— 


}_______]’_______J 
Figure 4.3: PWM 


Duty cycle is calculated as: 


'p 
iy Cycie — = 


A minimum pulse width of 0.6 milli-seconds, corresponding to —100 degrees, results in a 


duty cycle of: 
0.6 
Min. Duty Cycle (-100 deg.) = ae 0.015 


The maximum pulse width of 2.4 milli-seconds, corresponding to +100 degrees, results in 


a duty cycle of: 


2.4 
Max. Duty Cycle (+100 deg.) = Tye 0.06 


Assuming a linear relationship from minimum to maximum values, the following 


function is used to determine the required duty cycle for a given input in degrees. 
Duty Cycle = 0.0002 * (Desired deflection in degrees) + 0.0375 (Eq. 4.1) 


The algebraic block ‘Deg 2 PWM’ shown in Figure 4.4 implements this equation. 
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Figure 4.4: Deg 2 PWM SuperBlock 


Z Converting Volts to Degrees 


The output signal from sensors on the AROD, as described above, is the 
difference between the measured high voltage Vy and the centered voltage Vc. This 
voltage signal must be converted to the correct vane position in degrees for feedback to 
the RealSim controller and user display. Again it is assumed that there is a linear 


relationship from minimum to maximum deflection as shown in Figure 4.5. 


Degrees 





Figure 4.5: Volts to Degrees Conversion 


Therefore the measured output voltage from the sensor can be converted into correct vane 


position in degrees by: 
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200 
DO 2 Ol = rans ee) (Eq. 4.2) 


Vang ~ F mi00 


The algebraic block ‘Volts_2_Deg’ shown in Figure 4.6 implements this equation. 


Volts _2 Deg 





Figure 4.6: Volts 2 Deg SuperBlock 


C. SENSOR CALIBRATION 


Before the sensors can be used reliably by the controller, they must be calibrated. 
Due to small changes in the operating voltages, calibration is required each time the 
controller is started. The calibration process illustrated here for the AROD involves 
measuring the sensed voltages for vane positions of maximum deflection (-100 deg), 
minimum deflection (+100 deg), and the centered position (0 deg.). These measured 
voltage values are then used in Equation 4.2 to obtain the correct vane position. 
Referring to the Calibration JA screen shown in Figure 4.7, the calibration procedures 
are: 

e Command zero degrees of deflection using the “Deg cmd’ dial. Input the 

displayed voltage into the window labeled ‘V0’. 
e Repeat step 1 for max. (+100 deg.) deflection and min. (-100) deflection. 


e Confirm that the degrees sensed are the same as the commanded degrees. 
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Calibration 


Degrees cmd 





Voluage (Va) Degrees Sensed 


mm" 14.00 mms 814.00 


Duty Cycle B@owle 14.00 


Figure 4.7: Calibration IA Screen 


D. INPUT/OUTPUT CONNECTIONS 


The I/O configuration for AC/00 and America are given in Table I. The module 
numbers given in Table II are entered by the user to the hardware connection editor to 


define the type of I/O device required. 


Table I: I/O Configuration 


a 
ni ids 
—— | 
a. a 
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As an example, the HITL design project requires an IP_68322 I/O module for the 
PWM connection from the C30 to the AROD. The voltage signal from the AROD to the 
C30 uses the IP_ HiADC module. Appendix A includes the HCE input and output 
screens for this project. 

A brief description is given below for the I/O modules used in the avionics lab. 
References are also provided which contain more specific details on each module and 


procedures for making the required connections. 


il. Serial Connections/ IP_Serial Module 


The IP_ Serial module provides two channels of high performance multi-mode 
serial communication, [Ref. 6] section 5 page 69. Both RS-232-C and RS-422 are fully 
supported. The module can be programmed to baud rates of 2 Mbit/sec and 


asynchronous or synchronous protocols. 


2: Analog-to-Digital Connections/IP_HiADC 


The HiADC provides 16 input analog channels with 12-bit resolution and 
synchronous sampling of all inputs, [Ref. 6 ] section 5 page 61. The module can convert 
one analog channel in 1.2 usec or approximately 800 K samples/second. Each channel 
has a fixed voltage range of + 5 V. No anti-aliasing filtering is provided for by the 


module so inputs should be band-limited to 2 the sampling frequency of the system. 


3. Digital-to-Analog Connections/IP_DAC 


The DAC module provides six channels of 12-bit digital-to-analog conversion. 
Each channel can be configured to either + 5V or 0-10V output ranges, [Ref. 6] section 5 
page 34. 
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4. Pulse Width Modulation Connections/IP_ 68332 


The IP_68332 module is a time processing unit (TPU) that can perform one or 
more hardware I/O functions, [Ref. 6] section 5 page 52. It can be programmed to 
generate various digital I/O signals, the current set-up in the avionics lab will use Pulse 
Width Modulation (PWM) signals. In the PWM mode, the user specifies the duty cycle 


as the output from the SystemBuild diagram. 
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VV. DIGITAL CONTROL DESIGN 


The RealSim rapid prototyping series allows for control system to be tested in 
real-time with hardware-in-the-loop while recording any or all the state variables to 
verify performance. This section will step through the design process using a simple 


controller to control the control surfaces of the FROG. 


A. MODELING ACTUATORS AND SENSORS 


Before the controller can be designed, a mathematical model of the plant which is 
to be controlled must first be created. The techniques involved to develop the model 
depend on the characteristics of the plant. This section details the technique used to 
model the actuators used on the FROG. Since both the FROG and AROD’s control 
surfaces are actuated by Futaba FP S34 servo motors, the AROD is used in the lab. 

To develop an accurate representation of the Futaba actuators, the system is 


modeled as a second-order transfer function. 


z 
@ 


H(s) = ———__——_——. 
s°+2-€-@,-S+o@; 


The system response is obtained by applying a step function to the actuators and 
recording the response using the data acquisition editor feature of the RealSim software. 
To calculate the transfer function, the rise time f, and maximum overshot M, values are 
measured from the system response. From these values the natural frequency @, and the 


damping ratio € are calculated using the following formulae: 


oe (Eq. 5.1) 


~ fin, +2? 
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ee Ne (Eq. 5.2) 


It is assumed the actuators have a rate-limiter therefore a small step response of 
10 degrees is used so the effect of the rate-limiter on the rise time would be minimized. 
Then a larger step of 100 degrees is given to estimate the rate limits of the actuator. The 
results are plotted and shown in Figure 5.1 and 5.2. Note, to obtain a clearer picture of the 
actuators step response for the 10 degree step, the signal was fed through a lowpass filter 
with a cut-off frequency of 10 hertz. 

From the 10 degree step response plot, values for the maximum overshoot M, 
and rise time ¢, were measured as: 

Mie 22 t, = .06, 

From equations 5.1 and 5.2, the @, and € were calculated as: 


Gi CUD eG = 2455, 
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Figure 5.1: Step Response of Futaba Actuator (10 deg.) 
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Figure 5.2: Step Response of Futaba Actuator (100 deg.) 


The slope of the 100 degree step response is measured and used to calculate the 
rate-limiter, which was found to be approximately +325 deg./sec. 


The 2™ order transfer function can be given in general form by: 


a,s'+a,s” 
a 


JON = 
s) l+bs' +),s7 


where 


This transfer function was then implemented in SystemBuild, see Figure 5.3. Computer 
simulations were run on the model and the step response recorded and plotted along side 


the actuator’s step response for analysis. By changing the damping ratio and natural 
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frequency of the transfer function, the step response of the model was made to match the 


response of the actuator. The final values for the damping ratio and the natural frequency 


were: 
G =.55 
o,, = 25 
The step responses of the final second-order model and the actuator are shown in 
Figure 5.4. 
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Figure 5.3: Second Order Actuator Model 
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Figure 5.4: Step Response of Actuator and Second-Order Model 
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B. FEEDBACK CONTROLLER DESIGN 


The next step is to design a feedback controller that satisfies specific 
requirements. The requirements are normally specified in terms of response time, 


overshoot, stability and robustness. The controller design process is outlined below: 


e Create a nonlinear model. A block diagram is formed that includes the plant 


model! and nonlinear controller. 


e lLinearize the model and adjust controller gains. The linear model is 
linearized and then analyzed using frequency response and/or root-locus 


methods. 


e Analyze closed-loop system. Computer simulations are run with the feedback 


system, the controller gains are adjusted to create the desired control. 


Applying classical control techniques, the controller model is generally first 
designed in continuous-time. After a satisfactory response is achieved the system is 
transform to discrete-time and tested again for satisfactory response. 

For this example the Speed_Controller developed in Chapter IJ] is implemented 
with the actuator model. To analysis the system the loop between the controller and plant 
is broken as shown in Figure 5.5. The system is linearized using the Xmath command 
sys=lin(“SuperBlock name’). The linearized model can be used to analyze the system 
using root-locus methods and Bode frequency response methods. The root-locus and 
Bode plots, shown in Figure 5.6, are generated using the Xmath commands: rlocus(sys) 
and bode(sys). After a satisfactory response is obtained, the system is transformed to 


discrete-time and tested again. 
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C. HARDWARE-IN-THE-LOOP TESTING 


Hardware-in-the-loop testing 1s where the feedback system is tested with some or 
all of the actual hardware. In this case, the design will include the actuator, the actuator 
model and the Speed Controller, as shown in Figure 5.7. This design allows the 
controller to be simulated with the actuator model or conduct HITL testing. If the 
actuator model is accurate and the controller design is correct, there should be no 
apparent difference in the performance of the controller. If the actuators are not modeled 
well, the test of the controller may indicate that the controller works as designed while 


the HITL test may show that the feedback system is unstable. 
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Figure 5.7: HITL Test SystemBuild Block Diagram 


The simulation includes two switches for controlling the desired simulation state. 
The three simulation states are: 

e Sensor calibration 

e Actuator model 

e HITL 

The calibration switch controls which input command will be used by the 


actuators. With the calibration switch On, the command input Deg cmd is used. When 


aby, 


the switch is Off, the commanded input is from the error signal of the Vel cmd in the 
loop. The HITL switch will control which test is desired: the computer actuator model or 
the actual hardware. Table IJ summarizes these switch functions. The interactive 


animation page used to monitor and control the model is shown in Figure 5.8. 


Table IJ: Simulation States 
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Figure 5.8: [A Screen for HITL Test 
The HITL design includes a variable gain block, which permits the user to adjust 
the gain during the testing. The gain margin can be found experimentally by running the 


HITL test and slowly increasing the gain until the system goes unstable. The results are 
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shown in Figure 5.9. The gain margin when determined experimentally is approximately 


24 (-28db) which matches the gain margin found from the root-locus and bode plots. 
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Figure 5.9: Gain Margin Results From HITL Test 
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VI. ALTITUDE CONTROLLER DESIGN PROJECT 


This chapter details the design and implementation of a digital controller utilizing 
the rapid prototyping system. Applying classical control techniques, the goal is to design 
a PI controller to be implemented on the UAV FROG that will track constant altitude in 
steady-state. 


A. DESIGN REQUIREMENTS 


Design a PI controller for the combined model of the FROG and autopilot that 
satisfy the following requirements: 

e The feedback system must be stable. 

e The steady state tracking errors to constant altitude commands must be zero. 

e The overshoot to step commands in altitude should not exceed 20%. 

e The rise time in response to a step altitude command should be about 30 


seconds for a 100 ft climb. 


B. FROG AND AUTOPILOT MODELS 


The first step in the design process is to create a model of the aircraft. This 
model is developed from the equations of motion for the platform. A nonlinear model is 
first formed in a block diagram representation of these equations. The nonlinear model is 
then linearized about a desired trim point to create a linear model. There is also an 


autopilot installed in the FROG that must be modeled. The autopilot controls the elevator 
and aileron to command constant climb rate A, and constant yaw rate r,. The 
SystemBuild model for the combined FROG and autoplot was developed by a previous 


thesis student [Ref 7] and is shown in Figure 6.1, see Figure B.4 for the autopilot 
SuperBlock. 
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To determine the bandwidth available us , the control bandwidth is first 


determined. Figure 6.2 shows the —3db cutoff frequency equal to 2 rads/sec. 
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Figure 6.1: FROG and Autopilot Models 
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Figure 6.2: Elevator Control Bandwitdh 
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C. FEEDBACK CONTROLLER DESIGN 


The next step 1s to design a PI controller that satisfies the requirements outlined in 
section A. This is an iterative process employing various methods with the controller 
gains being the design knobs used to meet requirements of response time, overshoot, and 
command and control loop bandwidths. 

Applying classical control techniques, the initial controller gains are generally 
first obtained for continuous-time model. After a satisfactory response is achieved the 


system is transformed to discrete-time and tested again for satisfactory response. 


i: Basic SystemBuild Model 


The basic model is constructed with a PI controller and the complete FROG, 
autopilot, and actuator model developed in the previous chapter, and all known delays 
and nonlinearities. The known delays include: a transmission delay of 200 milli-second 
between the ground station and the FROG, and an update rate of approximately one 
second for the Global Positioning System (GPS) position. To model the GPS a ZOH 
function is developed using a discrete gain block with magnitude one and a sampling rate 


of T= 1 (sec). The complete system is shown in Figure 6.3. 
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Figure 6.3: Basic SystemBuild Model for Altitude Controller 


The following values of the PI controller gains were calculated to achieve the 


design requirements: 
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Pr 


1 — OO 
K, = 0.16 
The basic system is simulated using Xmath, and the step response is shown in 


Figure 6.4. 





Time 


Figure 6.4: Step Response for Initial Design 


A number of unsuccessful iterations were tried to reduce the overshoot of the step 
response while maintaining system stability. The nonlinear system is linearized as 
described in the next section. The linear model is then analyzed using root-locus 
methods and Bode frequency response. The analysis is demonstrated below. 


Consider the system transfer function 


M (yo HO us) — AL +K,)- POs) 
h. 1+ L(s) 14K 4K,)- POs) | 


where 
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LS) (CS) es) 
This results in an extra zero in the numerator at a , causing the overshoot. 
p 


Therefore a second design was developed. The PI controller was modified, as shown in 


Figure 6.5. 
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Figure 6.5: Modified PI Controller 


Now the system transfer function is 


K, 
h TA *P(s) 
Bred CS 
¢ 1+( + K,): PO) 
a 
LCS) 
This system was implemented using delta implementation [Ref. 8], as shown in Figure 


6.6. Note that SystemBuild does not have a differentiator block, therefore the following 


approximation 1s used: 


Ss 
sa — , where € <<] 
es +] 


This design showed a significant reduction in the amount of overshoot. The 
system response 1s shown in Figure 6.7. The initial value for K; produced a slower then 
desired response and was increased to .2 rads/sec. With a satisfactory step response 
observed in position and climb-rate, another simulation was run to check aircraft 


response to altitude commands, Figure 6.8. 


67 


Let 


act mee 


| 3 | 
SUPER 
1m#1G puock F* 


Contiruous 








. 
a 


a. ©) 


80 


2oO 





-20 
106 
e e 
e s 
e ) 
. 8 
Boe heal aN se ee ee 6s i eee SN tanga ae oo 
8 s 
: 
Pr 1 re a ee 
A Fle - - e©= © wo We - - - SF ee eee ee ee ee ee ee HH Hee ee Bee See ee soso saacacae = 
2 -=— ses es = — &= &— = = ee EN rere DN ae BN cn Se REE a acy eA Oa ge — ee = = = - = Oo —_— =—- = - «= 
8 
) 
: 
e 
© } ee me) se ee ee ee eS Se ns eg i nae 
: 
e 
2 
Oo 2O AO 60 BO 100 


Time 


Figure 6.7: Step Response for PI Controller 
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Figure 6.8: Dynamic Response of Model 


69 


es Linearized Model: Further Analysis 


To determine the stability margins of the system the root-locus and Bode analyses 
were done. The loop between the controller and plant was broken, Figure 6.9, and the 
system was linearized. The interactive root-locus feature of Xmath was used to 
determine the location of the system poles and the gain margin. The final results are 
shown in Figure 6.10, with a gain margin of —16db. The Bode plot was then generated 
and the command bandwidth of 0.2 rads/sec and the phase margin of 70 degrees were 
obtained, Figure 6.11. 

The system was then discretized by transforming the SystemBuild block diagram. 
Note: delay blocks must be added to each integrator to avoid algebraic loop in RealSim. 
The differentiator approximation used here is: 

s+() | -=-(1-z") 


The discrete model is shown in Figure 6.12. 
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Figure 6.9: Broken Loop Block Diagram 
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Figure 6.10 
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Figure 6.12: Discrete Altitude Controller Model 


D. HARDWARE-IN-THE-LOOP TEST 


The next step is a hardware-in-the-loop test. The actuators on the AROD set up in 
the avionics lab are the same actuators that control the elevator for the FROG. Therefore 
the HITL test can be conducted as described in the HITL section of this thesis. The 
necessary conversion blocks for the PWM output signal and voltage input signal were 
added to the controller design. Since the elevator command from the autoploit and 
FROG model is in radians, two more blocks were added to convert degrees and radians. 
The HITL SystemBuild model for the HITL testing is shown in Figure 6.13 and the test 


results are shown in Figure 6.14. 


E. IMPLEMENTATION AND FLIGHT TEST 


1. Implementation 


The final step is to implement the controller into the flight management system 
for the FROG. This system manages a number of functions including navigation and 


flight control. The SuperBlock structure of the flight management system is separated 


(Pp: 





100 


8oO 


40 


20 


eeeececcccnnesee 





act_mod 


Lo 
SUPER 
te] Stcce_ 


0.04 


autopilot 








j : | 
@ i 4 
i 
i ! i | : 
t H 1 
H t t i H : 
: j : i ; 
: i i : } 
iJ : ’ ' * 5 
OO . T . . : . Che 
F u i r A 
‘ x H i 
: ‘ ; : 
4 ‘ $ H 
6 3 1 s 
i i 
i] ¢ ' 5 j . 
iJ 
ee Seer T ppad| Poor oem-geune - eee eee 
rt , ' 
i j : j 
j ; H i 
Uy H ! H ‘ 
| 
F ¢ 8 { ‘ 
‘ 2 ; ‘ 
H i : : 
: es : : i t 
meccccccance POREOCACODOOBOLESAOICOY OSCE SECIS TS i a A eC SEbs aaa Reet ibh, CIEE LACE IOS s+ measn- Fa ae os emo en mnnntecennanans 
: i ; ; | 
i ; $ } 1 
: : : ; i 
5 . , , 
$ : $ 
H : : i 
' 1. . 
: : 
i : ->- 
1! 


: 
: : 
: : 
1 ‘ 
1 Oat a RT OOS Bie eminem ee ot min 
. : 
‘ ° 
' : 
1 ° 


. 
1 * 
e ' 
rf ry 
' . 
5 e 
SOREL Fe © Oi ae © Peers ey OS PS BED OOS SSS OS SEF OR HEH IEE EME SSI ES Glee He erh. 
. ° 
ry ° 
. ° 
ry 1 
. . 
. 1 
. 
. 
° 
ry 
. 
+ Re enon nce RES amr reee Oo oo pmME Oe Dem EE SS 
. 
° 
° 
. 
. 
* 
. 








s 
H 
8 s 
| { 
' 
1 I i 
Fy $ 
H . 
} t 
BY ARES DOTIECOOLO. HO CEOCEEE OBEN Ee COeoOe Jocccecccecenecnencnnscennnsecsnfacssernnnesscessnnsenscessecenmnscnsseaasanaassaesacescnaneasdhnessascen an scacaaesccecscs 
= J] 
7 e ; 4 
s i] 1 
i i i : 
: i r ; 
2 : t i 
1 3 A 
1 z 
H H H 4 
q a , 
> = 1 
2 ¢ = 
i 
; 5 3 
' : 
s oJ 


290 40 SO B80 100 120 


Figure 6.14: HITL Step Response For Altitude Controller 
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t40 


into five lower level SuperBlocks according to their function. The altitude controller is 
inserted into the control SuperBlock as shown in Figure 6.15. Appendix B contains the 
hierarchy for the SuperBlocks that make up the complete flight management system. 

The UAV can be controlled by either the computer or RC pilot with a standard 
RC Futaba transmitter. A complete description of the FROG and its components is given 
in [Ref. 9]. To prevent large control inputs during transitions from RC pilot to computer 
control, the altitude controller is implemented using a delta altitude as the input 
command. As an example, if the user desired to maintain level altitude at hand off, a 
command of zero should be given. A script block is used to freeze the GPS altitude 
position at hand-over. The delta commanded altitude is then summed with the frozen 
altitude position and is used as the entered altitude command for the controller. The 
controller outputs a climb-rate command to the autopilot. The feedback loop uses the 
GPS altitude position referenced with respect to the local tangent plane (LTP) at the field. 
The orientation of the frame is specified as North-East-Down (NED), therefore a 
conversion gain is added to the feedback loop to reverse the sign. A conversion gain is 
also added to the controller’s output. The FROG autopilot model differs from the actual 
autopilot in the units used for the entered climb-rate command. The model uses (ft/sec) 
where the actual autopilot uses (ft/min). The two switches are part of the wind down 
loop. If either or both switches are in the “OFF” position, the integrator is forced back to 
its initial value. This is done to prevent initiation of the controller at a previous state. 

Once the controller 1s added to the flight management system, the user interface 1s 
added in the Interactive Animation screen used to monitor and control the FROG. The 
necessary input/output devices are added to the existing throttle control IA page, shown 
in Figure 6.16. For the initial flight testing, the screen is designed to display a number of 
performance variables not normally used for an operational flight display. These displays 
help evaluate whether the controller is working properly. The two digital output displays 
show the commanded altitude and the actual GPS altitude in feet. When the altitude 
controller is operating and working properly, the altitude readouts should match. An 
open loop input for the climb-rate is also added. With this feature the climb-rate 


command can be given directly to the autopilot by the user. The input slide gage is added 
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to adjust the gain during the test. The trainer light in the middle of the page indicates 


who is controlling the vehicle, the computer or the pilot. 
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Figure 6.16: IA for Altitude Controller 
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M4 Flight Test 


The flight test is conducted at a RC modelers club airfield located near the Naval 
Postgraduate School. The RPS is completely portable, and fits easily in a car for 
transport to the field. A flight plan is written a couple of days prior to the flight 
describing the conduct of the test flight. After all flight checks have been completed, a 
face-to-face pilot briefing is given to review the flight conduct and hand-off procedures. 
Normally the hand-off is accomplished during steady-state level fight. 

Eight test runs were performed during two test flights. The data acquisition editor 
feature of the RealSim software was used to record the data. For each test run, the 
Airspeed Controller was used to maintain constant airspeed. The first three runs tested 
the performance of the Altitude Hold Controller in a turn. From the ground station, it 
appeared the controller maintained altitude within a +50 ft band. The next three runs 
tested the controller’s performance in response to climb commands. A 100 ft climb 
command was given from a straight and level altitude. Each time the controller 
responded well to the climb commands and leveled off appropriately. Once level, the 
FROG seemed to be chasing altitude. From observation, it was concluded the controller 
was chasing altitude due to GPS drift. Secondly, the aircraft was making rapid changes 
in pitch intermittently due to the latency in GPS data, as seen in Figure 6.17. To reduce 
the pitch activity a filter (s/s+3) was added to filter GPS altitude. Two more runs were 
conducted with the filtered GPS data. 

The test results for the controller in a turn are shown in Figure 6.17. The altitude 
error and commanded climb-rate from the controller show correct operation. As 
expected, the drift in the GPS caused the controller to chase altitude. The data shows 
many gaps of 3-5 seconds with no GPS update. Figure 6.18 details the results from the 
climb commands. As designed, the controller climbed to altitude and smoothly leveled 
off. The commanded climb-rate was well within the aerodynamic limits of the FROG 
and appropriate for thc climb. The performance of the controller with the filtered GPS, 
shown in Figure 6.19, was unstable with the errors slowly growing. 

Overall, the Altitude Controller performed as designed. The commanded climb- 
rate in response to the altitude error is good. The shortfall is the GPS sensor. Current 


plans include upgrading the FROG’s pitot-static system. With a reliable altimeter used as 
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feedback instead of GPS, a substantial improvement in controller performance would 


result. 
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Figure 6.18: Flight Test Results for Climb 
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Figure 6.19: Flight Test Results for Filtered GPS 
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Vil. CONCLUSIONS AND RECOMMENATIONS 


A. CONCLUSIONS 


The Advanced Controls of Aerospace Vehicles course, offered at the Naval 
Postgraduate School, provides an excellent opportunity for students to apply classical and 
modern control methods to the design of basic controllers. A strong foundation is 
presented on the operations and analysis of sampled-data systems. The rapid prototyping 
system, developed by the department, is an excellent design tool and allows the student 
valuable hands-on experience in the design, implementation and flight testing of control 
algorithms for unmanned air vehicles. The ability of the application software, RealSim, 
to automatically generate higher-language code and eliminate the time consuming task of 
programming the code for a working model, enables design projects ample time to be 
completed in the twelve weeks allotted for the course. 

Even though the RPS is still in its initial stages of development, it has generated a 
number of thesis opportunities, with many more foreseen in the future. Utilizing mostly 


off-the shelf technology, the cost of this educational tool will be minimal. 


B. RECOMMENDATIONS 


Considering the conclusions stated above and the knowledge gained in the course 
of instruction given in the Advanced Controls of Aerospace Vehicles, the following 


recommendations are forwarded: 


e Investigate scheduling this course, and its prerequisites, earlier in the avionics 
curriculum. The UAV program developed by the department produces many 
excellent opportunities for thesis work. To allow ample time for students to 
complete their thesis work, this class should be scheduled prior to the last 
quarter of instruction. 

e Presently there are no elective courses offered by the aeronautical engineering 


department in the area of digital control. Investigate the establishment of an 
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elective course that would introduce to the student system identification 
methods and advanced multivariable and optimal control procedures. 

Devote more classroom time to Design of Digital Control Systems Using 
Transform Techniques presented in Chapter V of [Ref. 1], and Design of 
Digital Control Systems Using State-Space Methods presented in Chapter VI 
of [Ref. 1]. Less time should be given to Chapter II of [Ref. 1], Linear, 
Discrete, Dynamic-Systems Analysis: The z-Transform. Material covered in 
chapter 2, discrete Fourier transform (DFT), z-transform, and block diagram 
descriptions, should be introduced during the prerequisite course, EO 2402, 
Introduction to Linear Systems. 

Establish a library within the avionics lab containing all previous thesis work 
and material related to the UAV FROG. Many of the design projects and 
future thesis work will build on the work from past projects. Good 
documentation is required to keep track of modifications, input/output 
variables, and improvements made to the system. 

Purchase a second target computer to supplement America. Currently the 
computer lab has only one computer with the AC100 model set-up and often 
two or three students end up waiting for access to America to compile and link 


their programs or to run the hardware setup. 
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Figure A.1: HCE Input Screen 
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Use lsFt mouse button, tab, snift-tab, or reaturn to selact items. 
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Figure A.2: HCE Output Screen 
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ADDITIONAL SUPERBLOCK DIAGRAMS 


APPENDIX B 
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Figure B.1 
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Figure B.4: FROG Auotpilot Model 
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